AWS App Meshのサーキットブレーカー機能を試してみた

はじめに

コンサル部のtobachi（@toda_kk）です。

2020年11月、「AWS App Mesh がサーキットブレーカー機能を導入」というアップデートが発表されました。すでにサービスメッシュとしてAWS App Meshを利用している場合、サーキットブレーカー機能を簡単に使えるようになったのではないかと思います。

今回は、実際に設定や確認の手順を試してみました。

AWS App Meshとは？

AWS App Meshでは、いわゆるマイクロサービスアーキテクチャにおいて重要視されるサービスメッシュと呼ばれる機能を提供してくれます。EC2/ECS/EKSのいずれの場合でも利用することができます。詳しくは公式ドキュメントやBlack Beltなどをご参照ください。

公式ドキュメントにもあるように、AWS App MeshはEnvoyをベースとしており、インスタンス/タスク/pod上で起動するEnvoyコンテナをproxyとして利用することで、サービスメッシュの機能を実現しています。

サーキットブレーカーとは？

その中でサーキットブレーカーとは、マイクロサービス群全体の可用性を高めるための仕組みです。サービス間における通信のコネクション数やリトライ回数をあらかじめ指定しておくことで、一部の通信やサービスで発生した障害がマイクロサービス群全体に 波及してしまわないように防ぐような仕組みです。

もともとAWS App Meshにおいて、サーキットブレーカーの機能そのものはEnvoyによって提供されていました。しかし、許容するコネクション数やリクエスト数の設定はEnvoyのデフォルト設定のままとなっており、変更するためにはproxyとして稼働するEnvoy自体の設定を変更する必要がありました。具体的には、Envoyの設定ファイル envoy.yaml を変更する必要がありました。

今回のアップデートでは、AWS App Meshに設定が追加されサーキットブレーカーを導入しやすくなりました。Envoyの設定を変更せずにAWSマネジメントコンソールやaws cliで設定できるようになったため、Envoyそのものの知識がなくても簡単にサーキットブレーカーを利用できるようになったのではないかと思います。

試してみた

公式のGithubリポジトリ上でドキュメントやサンプルが公開されているので、そちらに従って実際に試してみます。

手順通りに進めていくとAWS APP Meshが設定され仮想ゲートウェイや仮想ノードなどが作成されます。また、ECSクラスターが作られ、Envoyコンテナを含む形でサービスが立ち上がります。

そこで、AWS App Meshの設定を変更し maxConnections や maxRequests といった値を指定します。

まず、仮想ゲートウェイの値を設定します。下記の赤枠部分が該当の値になります。ここでは、最大コネクション数と、仮想ノードが受け付ける最大リクエスト数を超過した場合に保留しておくリクエスト数を設定しています。

次に、 colorteller-white-vn として立ち上がっている仮想ノードの最大コネクション数の値を 10 で指定します。

この状態で、60秒間にコネクション数101の状態でリクエスト数5000となるように指定した処理を colorteller-white-vn に対して送ってみます。実行後、proxyのメトリクスを見ると、仮想ゲートウェイのコネクション数が50前後になっている一方、対象の仮想ノードでは10程度で保たれているのがわかります。

続いて、 colorteller-black-vn として立ち上がっている仮想ノードの設定を変更します。今度は、最大リクエスト数の値を 10 で指定します。

同じように、この状態で colorteller-black-vn に対してリクエストを送ります。メトリクスを見ると、対象の仮想ノードのリクエスト数は常に 10 以下となるように保たれています。

おわりに

以上のように、Envoyの設定を直接いじらなくても、AWS App Meshの設定でサーキットブレーカーを利用することができました。サービスメッシュ導入の選択肢として、AWS App Meshのメリットが少し高まったかなと思います。

とはいえ、サーキットブレーカーを導入して終わりではなく、多くの場合は各設定値の具体的なチューニングが課題になってくるでしょう。そういった作業は引き続き根強く実施していく必要があるでしょう。願わくば、その辺のチューニングもなんか上手いこと良い感じにやってくんないかな……と思いますが、まあ地道にがんばるしかないっすね。